1. Field of the Invention
The present invention relates to a digital device, a task management method and a program therefor, and more particularly, to a digital device and a task management method for managing abortion of a task in a multitask operating system, and a program for causing a computer to implement associated functions.
2. Description of the Related Art
Conventionally, when a variety of functions are implemented mainly using software, for example, in a set-top box (STB: a general designation for devices such as a control box of a cable television, which are connected to home-use televisions for providing additional functions), a portable telephone and the like, the software is provided in the form of so-called embedded operating system (OS) which has previously stored an OS and programs for implementing the respective functions. Manufacturers which provide products provided with the embedded OS can sufficiently verify the operation of each function in the embedded OS and debug in a variety of operating states, so that they can offer highly reliable products which are stable in operation.
In recent years, some products may have a shorter lifetime, and new functions are added/changed at a shorter cycle as well. Therefore, a general OS has been used more and more in place of the embedded OS in products for flexibly accommodating such addition/change of functions. Further, with the development (diversification) of networks as well as proliferation of multifunction interpreter languages suitable for the networks as represented by Java, downloading of a program associated with addition/change of functions becomes easier, which also constitutes a factor of promoting the transition from the embedded OS to the general OS.
In the following, a general form of task execution will be described when the general OS is used. Since the general OS as described above normally operates as a multitask OS, the following description includes the multitask OS as well.
As illustrated in FIG. 5A, in a multitask OS, a plurality of processes 1, 2 (502, 503), for example, are executed on an OS 501. A plurality of threads are also executed in such a manner that a thread 1 (504) and a thread 2 (505), for example, are executed under management of the process 1 (502), a thread 4 (506) is executed under management of the process 2 (503), and the like. Upon execution, the process 1 (502),for example, is allocated resources such as a memory space, an I/O (Input/Output) space and the like from the OS 501, and the allocated resources are shared by the thread 1 (504) and thread 2 (505).
The process used herein refers to one execution unit of a program. More specifically, the process is a unit which independently possesses the resources and the like, and ensures the independence of each execution unit upon switching (upon switching processes by a multitask OS) by preserving all contents of CPU registers and loading register values for a process which is executed next. The thread is also one execution unit of a program, which enables multitask processing within the same process. While the units such as the process and thread are treated in different manners depending on particular OS, they can be said to be essentially one execution unit of a program and a set of functions. Thus, while the process and thread are properly used in the following description as required, both are similar in that they are tasks and constitute one execution unit of a program. In addition, an application is also a task in a broad sense.
Next, the structure of the aforementioned task (process and thread) will be described in brief. Generally, the task is comprised of a set of functions, and is executed, for example, in such a procedure that a predetermined function passes arguments to another function which passes a return value calculated using the arguments again to the predetermined function which then executes subsequent processing using the return value. Describing with reference to FIG. 6, for example, a task (thread 1) 601 includes an application function a (602) developed by a user as a main routine (main function), and calls an application function b (603) while it is processing the main routine. The application function b (603) further reads a system library function a (604) which is provided as a system library function as required, and the system library function a (604) calls an application function c (605). The functions called in course of the processing pass back respective return values calculated using arguments which have been given upon calling, and a function called in response to each return value executes subsequent processing.
In the foregoing manner, a plurality of functions constituting a task are individually processed to complete the processing of a predetermined task (main routine). The application function used herein refers to a function created as required, for example, by a person who programmed the task, and the system library functions refer to previously provided basic functions and the like. The application function and system library functions are both comprised of several tens to several thousands of steps, by way of example.
Each of the aforementioned thread 1 (504) and thread 2 (505) is executed in a processing time sequentially allocated by the OS 501, as shown in FIG. 5B. Specifically, the OS 501 allocates processing times 507 to 510 to the thread 1 and thread 2 (assume herein that the processing of a thread 3 is out of consideration) by means of a timer. In this event, the thread 1 is executed, for example, when the processing time 507 is first allocated by the OS 501, and the thread 2 is executed in the subsequently allocated processing time 508. In this manner, a plurality of processes can be executed in parallel by sequentially giving processing times to a plurality of threads (tasks) by the OS. In other words, the multitask OS can be implemented. The switching of threads (tasks) is referred to as “dispatch.”
The use of the general OS described above, the development (diversification) of networks, the proliferation of multifunction interpreter languages and the like enable flexible addition and the like of new functions to a variety of products.
After a modification of a system by addition and the like of new functions, a variety of use forms can be contemplated by combining the new functions. In such a situation, a large amount of resources are generally consumed, so that the resources cannot be allocated to programs which are to be executed later, thereby failing to initiate new programs. In order to avoid such a situation, conventionally, the task (process or thread) can issue, for example, an instruction for terminating the processing of another task, i.e., an abort instruction. The abort instruction can release resources so far allocated to a different task and initiate a new program. The lack of resources is more likely to occur in products which are limited in functions to some degree (for example, the aforementioned STB, portable telephone and the like), because such products are often provided with insufficient resources unlike general-purpose personal computers.
However, if one task is unreasonably permitted to abort the processing of another task, the other task may be aborted in the midst of important processing such as a data write. In order to address this problem, the technology described in Japanese Unexamined Patent Publication No. 10-69392 (1998) permits an “abort disabled section” to be set to a predetermined processing section to disable the abortion in the set processing section.
In the following, a mechanism of issuing an instruction for terminating the processing of a task, and the setting of the abort disabled section will be described with reference to FIG. 7.
Assume in FIG. 7 that a thread 1 (601) and a thread 2 (701) have been initiated as independent tasks on an OS. The thread 1 (601) and thread 2 (701) alternately execute the processing as appropriate through the aforementioned multitask processing. For example, as a processing time allocated to the thread 1 (601) expires, the thread 2 (701) next operates.
In this event, when the processing is switched to the thread 2 (701) at a time 702 at which a system library function a (604) is executed in the thread 1 (601), the thread 2 (701) executes the processing, for example, from an application function d (703).
Subsequently, suppose that at a predetermined point 705 during the processing on an application function e (704) in the thread 2 (701), the thread 2 (701) issues an abort instruction to the thread 1 (601), and the processing is switched to the thread 1 (601) at a predetermined point 706 in the application function d (703). In this event, the abort instruction is received, for example, during the execution of the system library function a (604) in the thread 1 (601), so that the thread 1 (601) is aborted, for example, by the OS during the execution of the system library function a (604) (immediately after the execution time 702). If the abortion of the processing by each of the functions (602 to 605) largely affects the overall processing, an abort disabled section is set in the following manner.
Specifically, at a predetermined point 707 of the application function a (602) in the thread 1 (601), the application function a (602) issues an abort disable instruction 708. The abort disable instruction is recognized and stored, for example, in predetermined processing in the OS. Next, as an abort disable instruction is issued by the thread 2 (701) at a predetermined point 705, similar to the foregoing, to switch the processing to the thread 1 (601), the OS, for example, determines whether or not the abort disable instruction has been issued. Since the abort disable instruction has been issued in this event, the abortion is not executed and normal processing is continued instead.
Subsequently, as the application function a (602) issues an abort enable instruction 710 at a predetermined point 709, the abort enable instruction is recognized, for example, in predetermined processing of the OS to conclude a section from the time when the abort disable instruction 708 was issued to the time when the abort enable instruction 710 is issued, i.e., the abort disabled section.
As the abort disabled section terminates, the OS, for example, reflects the abort instruction issued at the predetermined point 705 by the thread 2 (701) to abort the thread 1 (601) at the predetermined point 709 in the application function a (602).
By thus issuing the abort instruction between tasks (threads), it is possible to release resources used, for example,by another task. Moreover, when important processing (for example, a manipulation on a shared resource) which could affect the system is under execution, the important processing can be normally terminated by disabling the abortion from another task.
However, the aforementioned prior art, when used, will give rise to the following problems. If a program (software) including new functions, for example, is downloaded to a general OS using a network and executed on the general OS, the program may not normally operate, because of a wide variety of user environments, in contrast with the embedded OS, such as a plurality of different programs executed on respective devices. In such a case, the program must be aborted, but if the aforementioned abort disabled section has been set, the program cannot be aborted.
Particularly when a program created by a third party is downloaded through the Internet, the execution of the program may involve some risk because the program is not always created on a beneficial basis.
Specifically, if the thread 1 (601) shown in FIG. 7 is a malicious program, this program may execute an infinite loop, for example, in the application function b (603) to generate a thread having a similar application function b (603). In this event, if the malicious program is executed, threads will proliferate, and abort instructions to the threads will be invalidated by the setting of the abort disabled section. Eventually, a terminal (product) which has executed the program cannot be controlled by the OS, so that the terminal must be powered off.
Such a problem is not limited to products which use a general OS to provide particular functions but is likely to occur as well in Windows (R) and UNIX (R) which are common general-purpose OS.